TLS program header is not correctly generated for zero-initialized tls variables#1788
TLS program header is not correctly generated for zero-initialized tls variables#1788ostylk wants to merge 2 commits into
Conversation
|
Hi @ostylk. Do you intend to return to this PR? |
|
Hi, thank you for the reminder, this PR slipped my mind. |
|
All good, I was just checking in on PRs that hadn't been touched in a while. I don't think there's any particular hurry on this though. |
|
Ready for review but I have some comments/questions:
|
|
Welcome back! Regarding the CI failure - RexMovIndirectToAbsolute vs MovIndirectToLea, that sounds like something that could be caused by different defaults as to whether the binary is position independent or not. So possibly the difference might go away if you override those defaults - e.g. by passing a flag to make both linkers produce a position-independent binary. The PR in which we started putting zero bytes in the file for .tbss was #489. It unfortunately looks like I didn't add a test for it, so it's not impossible that something around there could have regressed. |
2 participants
I noticed the tls-common test failed on my machine depending on which environment and versions of compilers I used. It seems like the
TLSprogram header is generated incorrectly for zero initialized tls variables.E.g. in the tls-common we have a variable
tvarthat is in.tbss. However, the TLS program header isfilesz=4,memsz=4which doesn't zero-initialize it but loads bytes from the elf binary. It just so happens that all CIs and your local setup contained zeros in the binary at the exact place for this to nevertheless work. The correct TLS program header would befilesz=0,memsz=4.So this pull request does/will do two things:
//#ExpectProgramHeader:PT_TLS filesz=0,memsz=4and it will only accept if a program header with at least these properties exists.This is a draft because the test option still needs documentation and I haven't found the bug yet and holidays are starting. So I'll complete it at a later time.